A database is a structured collection of data and associated computer system components designed to provide a user access to meaningful information. A database is typically constructed upon a structural description of the information, referred to as a schema. The schema comprises a collection of meta-data that describes the relations among the data in the database.
The relational model for structuring databases is currently employed in many popular databases. In a typical relational database, a single database entry, referred to as a record, may contain one or more values, referred to as fields. Related records may be grouped together in a table, the definition of which controls the types of data each record may contain. Database records are often referred to as rows, because each record may be characterized as a row in a table. Individual fields are often referred to as columns, because field definitions are the same for each record within a table. Each column in a database table is characterized by a name and a data type. A database may contain multiple tables, each of which may contain multiple rows and/or columns.
Common functionality made available to a user of a database system includes the ability to add data, delete data, update data, retrieve data, and generate data reports. Structured Query Language (SQL) commands are commonly employed by database programmers and administrators to manipulate databases using such functions. The data type of each column governs how SQL may interact with the data stored in that column.
The comparable siring data types commonly supported by SQL include the following:
CHARACTER (n)—Character string. Fixed-length n
VARCHAR(n) or CHARACTER VARYING(n)—Character string. Variable length. Maximum length n
BINARY(n)—Binary string. Fixed-length n
VARBINARY(n) or BINARY VARYING(n)—Binary Variably length, Maximum length n
The comparable number date types commonly supported by SQL include the following:
BOOLEAN—Stores TRUE or FALSE values
INTEGER(p)—Integer numerical (no decimal). Precision p
SMALLINT—Integer numerical (no decimal). Precision 5
INTEGER—integer numerical (no decimal). Precision 10
BEGINT—Integer numerical (no decimal). Precision 19
DECIMAL(pss)—Exact numerical. precision p, scale s. Example: decimal (5,2) is a number that has 3 digits before the decimal and 2 digits after the decimal
NUMERIC(p,s)—Exact numerical, precision p, scale s. (Same as DECIMAL)
FLOAT(p)—Approximate numerical, mantissa precision p. A floating number in base 10 exponential notation The size argument for this type consists of a single number specifying the minimum precision
REAL—Approximate numerical mantissa precision 7
FLOAT—Approximate numerical mantissa precision 16
DOUBLE PRECISION—Approximate numerical mantissa precision 18
DATE—Stores year, month, and day values
TIME—Stores hour, minute, and second values
TIME STAMP—Stores year, month. day, hour, minute, and second values
INTERVAL—Composed of a number of integer fields, representing a period of time, depending on the type of interval
Some SQL implementations support also support an XML data type (i.e., stores data in an internal representation that preserves the Extensible Markup Language (XML) content of the data). Other data types sometimes supported by SQL include NCHAR and NVARCHAR. Unlike columns of either char or varchar type, columns of either nchar or nvarchar type can store Unicode characters. Columns of either char or nchar type are fixed-length, meaning they reserve storage space for number of characters specified whether or not that space is used. Columns of either varchar or nvarchar type are variable-length, meaning they only use space for the characters stored, and will not reserve storage like char and nchar types. Because columns of either nchar or nvarchar type may take up twice as much storage space than columns of either char or varchar type, a SQL programmer may opt to use the former types only if Unicode support is required. Also, SQL support for certain legacy data types has been dropped. For example, SQL programmers are advised to avoid non-comparable data types NTEXT, TEXT and IMAGE, and to instead use N VARCHAR(max), VARCHAR(max), and VARBINARY(max), respectively.
Although SQL became a standard of the American National Standards institute (ANSI) in 1986, and of the International Organization for Standardization (ISO) in 1987, revisions to supported SQL features has contributed to the problem that most SQL code is not completely portable among different database systems without adjustments. Consequently, custom SQL programming is often required to gain meaningful information out of a database that is unfamiliar to a user and/or which goal-specific SQL programming has not already been developed.
SQL programming can be cumbersome and error prone, even to specially-trained database users. Consequently, certain advancements in the area of intermediate-level database interface fools have been made in the software industry. For example, data grids are effective, albeit somewhat crude, multipurpose database manipulation tools. Microsoft's® GridView view mode is commonly used to access data from any SQL-compliant relational database and display those data in a format characterized by horizontal rows representing each record, and vertical lines dividing each column (e.g., each field of the record). However, when the limited display capabilities of this tool are called upon to present multiple columns and/or long-width columns, the immediate visibility of the desired data is constrained and inefficient. Furthermore, augmenting simplistic grid-based tools with, for example, a user-friendly interface and/or user-specified data views requires expensive, situation-specific downstream database application programming, which precludes their development and use by other than users who are proficient in SQL command syntax.
A need exists for an alternative software tool for creating a stand-alone, user-directed interface to a database that may equip end users having varying levels of SQL literacy to access and present meaningful information from a database without having to resort to complex SQL programming.
While certain aspects of conventional technologies have been discussed to facilitate disclosure of the invention, the applicant in no way disclaims these technical aspects, and it is contemplated that the claimed invention may encompass one or more of the conventional technical aspects discussed herein. The present invention may address one or more of the problems and deficiencies of the current availability and prior art discussed above. However, if is contemplated that the invention may prove useful in addressing other problems and deficiencies in a number of technical areas. Therefore, the claimed invention should not necessarily foe construed as limited to addressing any of the particular problems or deficiencies discussed herein, or limited to the particular embodiment for the invention used to illustrate the steps and functionality of the herein.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention. This reference or discussion is not an admission that the document, act or item of knowledge or any combination thereof was at the priority dale, publicly available, known to the public, part of common general knowledge, or otherwise constitutes prior art under the applicable statutory provisions; or is known to be relevant to an attempt to solve any problem with which this specification is concerned.